Gemini 3.x rejects a replayed function call whose thought_signature is missing, so the agent dies on its second step:

400 INVALID_ARGUMENT: Function call is missing a thought_signature in
functionCall parts. This is required for tools to work correctly.
Additional data, function call `default_api:goto_tool`, position 2.

Step 1 succeeds (the browser navigates), then every retry fails and the run aborts. This makes the agent unusable on current Gemini models — gemini-2.5-flash and gemini-2.0-flash now return 404 ... no longer available to new users for new API keys, so new users land on a 3.x model by default.

Root cause

The Google provider already handles both ends of this:

• extracts the signature from the response — src/providers/google/llm.py:321 (_extract_thought_signature, into Thinking(signature=...))
• replays it onto the function-call Part when rebuilding history — src/providers/google/llm.py:121-126

The gap is between them. src/agent/service.py built its ToolMessage from the LLMEvent without thinking or thinking_signature, so the extracted signature was discarded before it could ever be replayed. ToolMessage.thinking_signature is declared in src/messages/service.py:150 but nothing assigned it anywhere in the codebase.

Fix

Thread both fields from the LLMEvent into the ToolMessage (2 lines).

Also affects Anthropic

src/providers/anthropic/llm.py:148,160 reads the same msg.thinking_signature that nothing previously set, so extended thinking with tools was likely broken in the same way. This fix is provider-agnostic and should repair that path too — though I verified on Gemini only.

Verification

With gemini-flash-latest:

• before: fails at step 2 with the error above, all 3 retries exhausted
• after: a multi-step navigate-and-extract task completes and returns its final answer

Happy to add a regression test if you would like one — a fake provider returning a signature and asserting it survives the history round-trip would cover it.